Loadstar 128 #32/q32side1.d64/t.lil red 2

Text File | 1992-01-01 | 14.3 KB | 277 lines

              LITTLE RED READER  Version 2.00  (March 8, 1994)

        MS-DOS file reader/writer for the C128 and 1571/81/FD drives

      Program and Text by Craig Bruce  ([e-mail])

              Interface Changed by Fender Tucker (May 8, 1996)


2.3. COPYING MS-DOS TO CBM-DOS

When you enter copy mode, the screen will clear and the name of each
selected file is displayed as it is being copied.  If an error is
encountered on either the MS-DOS or CBM-DOS drive during copying, an error
message will be displayed and copying will continue (after you press a key
for MS-DOS errors).

To generate a CBM-DOS filename from an MS-DOS filename, the eight filename
characters are taken (including spaces) and a dot (.) and the three
characters of the extension are appended.  Then, all spaces are removed,
and if the name ends with a dot (.) character, then that dot character is
removed as well.  I think this is fairly reasonable.

If there already is a file with the same filename on the CBM-DOS disk, then
you will be prompted if you want to overwrite the file or not.  Entering an
"n" will abort the copying of that file and go on to the next file, and
entering a "y" (or anything else) will cause the CBM-DOS file to be
"scratched" and then re-written.

The physical copying of the file is done completely in machine language and
nothing is indicated on the screen while this is happening, but you can
follow things by looking at das blinkin lichtes and listening for clicks
and grinds. You will probably be surprised by the MS-DOS file reading speed
(I mean in a good way).  The disk data is read in whole tracks and cached
in memory and the directory information and the FAT are retained in memory
as well.  The result is that minimal time is spent reading disk data, and
no costly seeks are required for opening a new MS-DOS file.  A result is
that small files are copied one after another very quickly.  You will have
to wait, however, on the relatively slow standard kernel/Commodore-DOS file
writing.

A few changes had to be made to the program to accomodate the RAMDOS
program. RAMDOS uses memory from $2300 to $3FFF of RAM0, which is not
really a good place for a device driver, and it uses some of the zero-page
locations that I wanted to use.  But, difficulties were overcome.  The
importance of RAMDOS compatibility is that if you only have one disk drive
but you have an REU, you can use RAMDOS to store the MS-DOS files
temporarily.  If you only have one disk drive and no REU, you are SOL (Out
of Luck) unless you can get a RamDisk-type program for an unexpanded 128.
The RAMDOS program is available from FTP site "ccosun.caltech.edu" in file
"/pub/rknop/util128/ramdosii.sfx". One note I found out about RAMDOS: you
cannot use a

DOPEN#1,(CF$),U(CD),W

with it like you are supposed to be able to; you have to use a

DOPEN#1,(CF$+",W"),U(CD)

Here is a table of copying speeds for copying from 1571s and 1581s with ASC
and BIN translation modes.  All figures are in bytes/second.  These results
were obtained from copying a 127,280 byte text file (the text of C= Hacking
Issue #3).

   FROM    TO: "null"     RAMLink     RAMDOS     JD1581     JD1571
  -------      ------     -------     ------     ------     ------
   81-bin       5772        3441       2146        n/a        644
   81-asc       5772        3434       2164        n/a        661
   71-bin       4323        2991       1949       1821        n/a
   71-asc       4323        2982       1962       1847        n/a

The "null" device is that "0" CBM-DOS device number, and a couple of
entries are "n/a" since I only have one 1571 and one 1581.  Note that my 71
and 81 are JiffyDOS-ified, so the performance of a stock 71/81 will be
poorer.  JiffyDOS gives about a 2x performance improvement for the standard
file accessing calls (open, close, chrin, chrout).  RAMDOS doesn't seem to
be as snappy as you might think.

The "null" figures are quite impressive, but the raw sector reading speed
without the overhead of mucking around with file organization is 6700
bytes/sec for a 1581 and 4600 B/s for a 71.  The reason that the 1571
operates so quickly is that I use a sector interleave of 4 (which is
optimal) for reading the tracks.  I think that other MS-DOS file copier
program uses an interleave of 1 (which is not optimal).  I lose some of the
raw performance because I copy the file data internally once before
outputting it (to simplify some of the code).

In a couple of places you will notice that ASC translation gives slightly
better or slightly worse performance than BIN.  This is because although
slightly more work is required to translate the characters, slightly fewer
characters will have to be written to the CBM-DOS file, since PETSCII uses
only CR where MS-DOS ASCII uses CR and LF to represent end-of-line.
Translation is done by using a table (that you can change if you wish).
Many entries in this table contain a value of zero, which means that no
character will be output on translation.  Most of the control characters
and all of the characters of value 128 (0x80) or greater are thrown away on
being translated.  The table is set up so that CR characters are thrown
away and the LF character is translated to a CBM-DOS CR character.  Thus,
both MS-DOS ASCII files and UNIX ASCII files can be translated correctly.


2.4. COMMODORE-DOS MENU

The Commodore-DOS menu, which displays the names of the Commodore files
selected for various operations, looks and works pretty much the same as
the MS-DOS menu:

   CBMDOS  MS=10:1581  CBM=8  FREE=3211476

   NUM  S  TRN  FILENAME         T  LENGTH
   ---  -  ---  ---------------- -  ------
     1  *  BIN  LRR-128          P    9876
     2     ASC  COM-HACKING-005  S  175412

   D - Directory  M - MS Device  F - CBM Device  C - Copy  Q=Quit
   T - Toggle All  R - Remove  X - CBM Copy  / - Switch  +/- Page

You'll notice, however, that the filetype field ("T" here) is moved and is
unchangable.  Also, the file lengths are not exact; they are reported as
the block count of the file multiplied by 254.  This menu is not maintained
for files being copied to the CBM-DOS disk from an MS-DOS disk.  You'll
have to re-execute the Directory instruction to get an updated listing.

The "D" (directory) command has local effect when in this menu.  The
Commodore-DOS directory will be loaded from the current CBM device number.
Note that in order for this to work, the CBM device must be number eight or
greater (a disk drive).  Originally, the subroutine for this command was
written using only GET#'s from the disk and was very slow.  It was
modified, however, to call a machine language subroutine to read the
information for a directory entry from the directory listing, and hence the
subroutine now operates at a tolerable speed.

The "C" (copy) command also has a different meaning when in this menu.  It
means to copy the selected CBM files to the MS-DOS disk.  See details
below.

The copy CBM files ("X") command is used to copy the files in the CBM-DOS
menu to another CBM-DOS disk unit.  Select the files you want to copy and
then press X.  You will then be asked what device number you want to copy
the files to.  The device can be another disk drive or any other device
(except the keyboard).  Using device number 0 does not mean the "null"
device as it does with copying MS-DOS to CBM.  If you are copying to a disk
device and the file already exists, then you will be asked if you wish to
overwrite the file.  You cannot copy to the same disk unit.  Also, all
files are copied in binary mode (regardless of what translation you have
selected for a file).

The copy CBM files command was included since all of the low-level gear
needed to implement it (specifically "commieIn" and "commieOut" below) was
also required by other functions.  This command can be very convenient when
working with RAMDOS.  For example, if you only had a 1571 as device 8 but
you have a RAM expander and have installed RAMDOS as device 9, then you
would copy MS-DOS files to RAMDOS using the MS-DOS menu, and then you would
go to the Commodore-DOS menu ("/"), read the directory, select all files,
insert an Commodore-DOS diskette into your 1571, and then use "X" to copy
from the RAMDOS device to the 1571.

The remove command ("R") does not work for this directory.  You can SCRATCH
your CBM-DOS files your damn self.

 FENDER'S NOTE: Hey, I thought only Knees Calhoon had the nerve to say
stuff like that.


2.5. COPY CBM-DOS TO MS-DOS

Before you can copy selected CBM-DOS files to an MS-DOS disk, the MS-DOS
disk directory must be already loaded (from the MS-DOS menu).  This is
required since the directory and FAT information are kept in memory at all
times during the execution of this program.

When you enter copy mode, the screen will clear and the name of each
selected file is displayed as it is being copied.  If an error is
encountered on either the MS-DOS or CBM-DOS drive during copying, an error
message will be displayed and copying will continue (after you press a key
for MS-DOS errors).  Please note that not a whole lot of effort was put
into error recovery.

To generate an MS-DOS filename from an CBM-DOS filename, the following
algorithm is used.  The filename is searched from right to left for the
last "." character.  If there is no "." character, then the entire
filename, up to 11 characters, is used as the MS-DOS filename.  Characters
9 to 11 will be used as the extension.  If there is a "." character, then
all characters before it, up to eight, will be used as the MS-DOS filename
and all characters after the final ".", up to three, will be used as the
MS-DOS extension.

Then, the newly generated MS-DOS filename is scanned for any extra "."
characters or embedded spaces.  If any are found, they are replaced by the
underscore character, which is the backarrow character on a Commodore
display.  Finally, all trailing underscores are removed from the end of
both the filename and extension portions of the MS-DOS filename.  Also, all
characters are converted to lowercase PETSCII (which is uppercase ASCII)
when they are copied into the MS-DOS filename.  Note that if the Commodore
filename is not in the 8/3 format of MS-DOS, then something in the name may
be lost. Some examples of filename conversion follow:

 CBM-DOS FILENAME       MS-DOS FILENAME
 ----------------       ---------------
 "lrr.bin"              "lrr.bin"
 "lrr.128.bin"          "lrr 128.bin"
 "hello there.text"     "hello th.tex"
 "long filename"        "long fil.ena"

It would have been time-consuming to have the program scan the MS-DOS
directory for a filename already existing on the disk, so LRR will put
multiple files on a disk with the same filename without complaining.  This
also gets rid of the problem of asking you if you want to overwrite the old
file or generate a new name.  However, in order to retrieve the file from
disk on an MS-DOS machine, you will probably have to use the RENAME command
to rename the first versions of the file on the disk to something else so
MS-DOS will scan further in the directory for the last version of the file
with the same filename.  There is no rename command in LRR because I never
thought of it in time.  It would have been fairly easy to put in.

The date generated for a new MS-DOS file will be all zeros.  Some systems
interpret this as 12:00 am, 01-Jan-80 and others don't display a date at
all for this value.

The physical copying of the file is done completely in machine language and
nothing is displayed on the screen while this is happening, but you can
follow things by looking at the blinking lights and listening for clicks
and grinds.

Since the FAT and directory are maintained in RAM during the entire copying
process and are only flushed to disk after the entire batch of files are
copied, copying is made more efficient, since there will be no costly seek
back to track 0 after writing each file (like MS-DOS does).  If you have a
number of small files to copy, then they will be knocked off in quick
succession, faster than many MS-DOS machines will copy them.

To simplify the implementation, the current track of disk blocks for
writing is not maintained like it is for reading.  Also, a writing
interleave of 1:1 is used for a 1571, which is not optimal.  However, since
writing is such a slow operation anyway, and since the 1571 is particularly
bad by insisting on verifying blocks, not much more overhead is introduced
than is already present.

An interesting note about writing MS-DOS disks is that you can terminate
LRR in the middle of a copy (with STOP+RESTORE) or in the middle of copying
a batch of files, and the MS-DOS disk will remain in a perfectly consistent
state afterwards.  The state will be as if none of the files were copied.
The reason is that the control information (the FAT and directory) is
maintained internally and is flushed only after copying is all completed.
But don't terminate LRR while it is flushing the control information.

 FENDER'S NOTE: I removed the "Flushing" message, so let's just say "Don't
terminate LRR while it is accessing the drives in any way."

Here is a table of copying speeds for copying to 1571, 1581, and CMD FD-
4000 disk units with ASC and BIN translation modes.  All figures are in
bytes/ second, which includes both reading the byte from a C= disk and
writing it to the MS-DOS disk.  The average speed for either the read or
write operation individually will be twice the speed given below.  These
results were obtained from copying a 156,273 byte text file (the text of C=
Hacking Issue #4).

 FROM    TO: FD-bin     FD-asc     81-bin     81-asc    71-bin    71-asc
 --------    ------     ------     ------     ------    ------    ------
 RAMLink      2,332      2,200      2,332      2,200     1,594     1,559
 RAMDOS       1,070      1,053      1,604      1,600     1,561     1,510
 FD4000           -          -      1,645      1,597     1,499     1,464
 JD1581       1,662      1,619          -          -     1,474     1,440
 JD1571       1,050      1,024        953        933         -         -

These figures are for transfer speed only, not counting the couple of
seconds of opening files and flushing the directory.  Note that all my
physical drives are JiffyDOS-ified, so your performance may be slower.  I
am at a loss to explain why an FD-4000 is so much slower than a 1581 for
copying from a RAMDOS file, but the same speed or better for copying from
anything else.

                        \\\\\ RETURN - Menu \\\\\